Broadcast encryption refers to a set of cryptographic key management schemes whose common property is allowing two parties to agree upon a key without having a two-way conversation. Instead, the parties have a one-way flow of cryptographic data—hence the word “broadcast”. In contrast, public-key cryptography systems require two-way handshakes between the parties before sharing a cryptographic key. One purpose of broadcast encryption and public-key cryptography is to protect content from unauthorized copying or distribution. Content comprises movies, audio, software, photographs, or any other digital information. Content is distributed via a media such as, for example, recordable disks comprising DVDs, etc.
In the short history of broadcast encryption, there has been a steady improvement in performance as new schemes of broadcast encryption have been introduced. For example, early conventional broadcast encryption schemes had a finite, albeit arbitrarily large, revocation capability. Another conventional broadcast encryption system has been introduced based on a tree-based scheme; this conventional approach has effectively unlimited revocation. For these conventional approaches, the broadcast encryption revocation information is substantially larger than a public-key revocation list for an equivalent amount of revocation. This broadcast encryption revocation information is referenced herein as a media key block. A further broadcast encryption scheme comprises a “subset-difference” scheme in which the media key block is of the same order of size as a revocation list.
Broadcast encryption comprises several characteristics. Broadcast encryption is one-way (hence “broadcast”); i.e., broadcast encryption does not require a two-way handshake for two parties to securely agree upon a cryptographic key. Broadcast encryption requires relatively few computational resources compared to public key calculations. Because the revocation information is inherently tied to the media key block and hence to the cryptographic key protecting content, broadcast encryption easily links revocation information and the content. Broadcast encryption is inherently anonymous; parties can prove they are compliant because they can correctly process the media key block. However, parties do not have to reveal anything else.
Because of these characteristics, broadcast encryption has become a technology of choice for content protection applications. In some cases, such as protected DVDs, broadcast encryption is essential because of its one-way nature. It is impossible to carry on a two-way conversation with a piece of plastic such as a DVD. However, even in other cases such as secure digital flash memory cards where two-way handshakes are possible, broadcast encryption is used for the other reasons stated above. To date, over 500 million consumer electronics devices have been manufactured using broadcast encryption such as content protection for recordable media (CPRM) and advanced access content system (AACS).
Although conventional broadcast encryption technologies have proven to be useful, it would be desirable to present additional improvements. Conventional broadcast encryption has not been able to mimic the digital signature function normally available in a public-key system. Instead, a conventional broadcast encryption system uses message authentication codes (MACs) to attest for the validity of messages in the system. In this context, a message authentication code comprises the following distinguishing properties:
Validity testing property—only valid participants in the system (those that have a set of broadcast encryption keys) can test the validity of a given message authentication code; and                Identification property—Any valid participant can produce any message authentication code; a participant is not required to produce identification.        
The validity testing property of conventional broadcast encryption is rarely a limitation in practical systems. The identification property allows the participants to operate anonymously while still proving that they are valid and compliant. Anonymity can be desirable in some applications; in particular, the copy protection application is usually cited as the prime example. For example, when a recording device makes an encrypted “do not copy” recording, the recording device is not concerned with an identity of a playing device that plays the recording. Rather, the recording device is only concerned with whether the playing device that plays the recording is compliant with distribution agreements and does not produce unauthorized copies.
In a copy protection application, however, there can be cases where anonymity is a disadvantage. Consider the case of the advanced access content system (AACS), the copy protection scheme for a new generation of high-definition blue-laser DVD movie discs. The advanced access content system is based on a subset-difference broadcast encryption scheme, referenced as “NNL” after the authors. The advanced access content system recognizes at least two types of DVD recordings: stream recording of content transmitted by television signals and prepared full-movie content via “electronic sell-through”. Protection is required for the content transmitted by television signals because, for example, the content is provided by premium cable channels. The prepared full-movie content comprises rich navigation and bonus content. A consumer obtains the prepared full-movie content by downloading the prepared full-movie content from a server onto a recordable disk in the home of the consumer; this process is referenced as “electronic sell-through”.
Any licensed recorder may record the content transmitted by the premium cable channel. However, only a relatively few servers are necessary to produce the disk images for the content comprising rich navigation and bonus content. In this application, additional security is desirable that enables a server to attest that a given recordable movie disk came from one of the legitimate servers and not from a circumvention device using broadcast encryption keys stolen from one of the millions of recorders.
This server attestation can be easily provided in a public-key system. A legitimate server has a properly signed digital certificate identifying the public key of the legitimate server. When the legitimate server downloads to a recordable disk the full-movie content, the certificate of server, and a signed token that affirms that the full-movie content recorded on the recordable disk came from the legitimate server. In other words, the legitimate server signs the unique serial number of the recordable disk. A compliant player does not play the full-movie content on the recordable disk unless the recordable disk has a validly-signed certificate and a validly-signed token that matches the serial number of the recordable disk.
Although public key encryption technologies have proven to be useful, it would be desirable to present additional improvements. In the application such as that of server downloading full-movie content to a recordable media, public-key calculations are inherently more onerous than broadcast encryption calculations. As an example, checking a signature in the standard public-key scheme chosen by the Advanced Access Content System takes 28,000,000 instruction, while checking a message authentication code takes 200 instructions. It is desirable to avoid this overhead in consumer electronics devices such as DVD players, which are very cost sensitive. Furthermore, broadcast encryption is necessary to calculate the cryptographic key that encrypts the full-movie content; it is not possible to conduct a public-key handshake with an inert piece of plastic like a DVD. To overlay the required broadcast encryption scheme with an additional public-key infrastructure is less efficient, more error-prone, and requires additional processing by the DVD player.
In some applications of broadcast encryption, not all participants are equally trusted and it is desirable to have a cryptographic proof of identity for at least some of the participants. For example, consider again the case of “electronic sell-through” in which content is downloaded onto a recordable DVD instead of selling the content as a prerecorded DVD in a store. Through well-known conventional mechanisms, the electronic sell-through server customizes the downloaded movie to the particular media ID on the recordable disk in the possession of the user. This process involves cryptographically binding the media ID of the recordable disk to the media key block in the movie, generating binding data that is written to the recordable disk. Compliant players only play the movie when this binding data is correct, so attackers cannot make extra copies by copying the movie to other discs. Each of the recordable disks has different media IDs burned in at manufacturing time and not changeable by the user.
However, any device with a set of device keys can produce that correct binding data because the device can calculate the media key in the media key block. For this particular purpose, only the server is required to calculate the media key in the media key block. The playing devices must calculate the media key to play the content correctly. If a set of attackers can obtain a set of unrevoked device keys, the attackers can set up a rogue server that can copy movies on demand. This attack has been referred to as the “Garage Replicator Attack”. Any set of device keys may work; the anonymity of broadcast encryption is actually working against it in this application. The keys obtained by the attackers can be revoked, but only after determining which sets of device keys are being used by the attackers. What is needed is a way for the electronic sell-through the server to have special cryptographic status that allows only the authorized server to correctly perform the binding process.
Achieving this special cryptographic status for the electronic sell-through server is straightforward when using public-key cryptography. The electronic sell-through server is given a certificate, signed by the licensing agency of the content protection scheme. The certificate identifies the electronic sell-through server as an authorized server and identifies the public key of the electronic sell-through server. Each time the electronic sell-through server sells a movie, the electronic sell-through server produces a token by signing the media ID with the private key associated with the electronic sell-through server. The electronic sell-through server passes the token and the certificate to the client; the client places the token and the certificate on the disk together with the movie. Every compliant player is required to check that the certificate is valid and signed, that the token corresponds to the actual media ID on the disk, and that the token is signed by the server identified in the certificate.
However, using a public key approach in an electronic sell-through application requires the media recorder of the user to expend a considerable amount of computational overhead when checking the signature. Likewise, the server expends a considerable amount of computational overhead to generate the signatures, limiting the number of transactions per second it can perform. This public key approach further requires additional computational overhead when performing the revocation of servers. This process can create a noticeable delay.
What is therefore needed is a system, a service, a computer program product, and an associated method for cryptographically authenticating data items. Such a system is desired that provides the functionality of a public-key signature without the computation overhead required by public-key cryptography and that ties revocation information to the encrypted content so that revocation cannot be bypassed in an attack. The need for such a solution has heretofore remained unsatisfied.